# Долгосрочное домашнее задание
Группа разбивается на подгруппы по 3 человека (возможно только одно исключение - одна группа из 2 или 4 человек, если общее число слушателей в учебной группе не кратно 3-м).

На выбор есть восемь вариантов задания:
* Вариант 1 - Игра "[Питон](python.md)"
* Вариант 2 - Игра "[Шашки](checkers.md)"
* Вариант 3 - Игра "[Реверси](reversi.md)"
* Вариант 4 - Игра "[Трон](tron.md)"
* Вариант 5 - Игра "[Попрыгунчик](jumper.md)"
* Вариант 6 - Игра "[Пакман-убийца](packiller.md)"
* Вариант 7 - Игра "[Танчики](battlecity.md)"
* Вариант 8 - Игра "[Шутер](shooter.md)"

Минимальный набор инструментов для выполнения этапов ДДЗ, который необходимо изучить и использовать для разработки приложения:

* IDE для разработки (CLion, язык c++)
* Библиотека SFML (документация и книги с примерами разработки игр, меню в каталоге [info/Библиотека/SFML](https://gitwork.ru/sub/tpro/-/tree/master/info%2F%D0%91%D0%B8%D0%B1%D0%BB%D0%B8%D0%BE%D1%82%D0%B5%D0%BA%D0%B0%2FSFML), там же можно найти примеры реализации игры Arkanoid)
* Совместный GIT-репозиторий 

Возможность реализации с использованием других средств разработки и языков программирования необходимо обсудить с преподавателем, в целом можно использовать любую удобную вам среду разработки, главное использование системы контроля версий и системы управления проектами. Проверяется в первую очередь работа с ними.

Работу вести в совместном Git-репозитории (см. [Задание 3 по командной работе](../task3.md)). 

Один из разработчиков в команде выбирается **руководителем команды**, он создает в своей учетной записи проект с названием **tpro-ddz** (его роль - maintainer, обозначим его как "участник 1") и подключает туда остальных участников команды - **разработчиков** с ролями Developer (обозначим их как участники 2 и 3).

ДДЗ состоит из различных по сложности этапов, каждый этап - это небольшое домашнее задание, которое необходимо сдать **группе**. 

Начальное состояние репозитория - проект с README.md, в котором изложена цель и указаны роли с номерами разработчиков (использовать только fullname, никаких фамилий) с перечнем функционала для реализации. 

Каждый участник берёт фрагмент функционала из своего перечня и создаёт issue, по номеру (N) этого issue создаёт ветку для разработки (feature-branch). Ветка называется по формату N-feature, например, ветка "3-main-win" для issue номер 3 про создание главного окна программы. Название ветки должно быть максимально коротким - одно два слова. По завершении своего функционала участник создаёт MR, для code review назначается assignee на следующего по номеру участника команды. Второй частник должен назначить assignee третьему участнику команды (по кругу). Смысл такого review - чтобы каждый участник ориентировался во всей кодовой базе, а не только в своём фрагменте.

Если кто-то из участников не согласен с кодом, он должен вернуть issue с замечаниями и только правильный код должен заслужить Merge.

В MR ведётся обсуждение и исправление кода до того момента, пока все замечания reviewer-а не будут устранены. Reviewer должен самостоятельно запустить изучаемую ветку на своей машине и убедиться в работоспособности, в обсуждении указать на проблемы и ошибки. **Ответственность за код, прошедший code review, несёт code reviewer**. После одобрения кода всеми участниками assingee переводится на руководителя, руководитель завершает merge request путём нажатия merge. Исходную ветку не удалять (галочка на удаление должна быть снята при merge).

Когда решена очередная задача разработки, руководитель должен собрать общую версию в master и снабдить её аннотированным тэгом по номеру задачи: v1, v2, и так далее. Разработка после этого продолжается, при этом конкретную версию можно сдавать преподавателю. За работоспособность кода при сдаче несёт ответственность руководитель. Преподаватель опрашивает по всему коду любого из участников. Сдача или несдача носит коллективный характер - если один из участников не отвечает, работа не зачитывается всей группе.

README должен содержать описание текущего этапа, инструкции по установке, запуску и проверке работоспособности. Совет - инструкции по проверке работоспособности писать в самом начале этапа, чтобы каждый понимал - что должно быть в результате.

По окончанию каждого этапа разработки должен быть подготовлен краткий печатный отчет (один на группу), содержащий описание решаемой задачи, краткое описание проведенных действий. **Итого два отчета**.

## Требования к отчёту

Отчет представляет собой материал, который в обязательном порядке представляется обучающимся преподавателю в течение семестра. Он содержит описание результатов выполнения задания, обоснование принятых решений, а также доказательство работоспособности разработанной программы. Объем отчета обычно не превышает 10-20 страниц.

Принятый отчет о выполнении долгосрочного домашнего задания является критерием положительной оценки на экзамене по учебной дисциплине - отсутствие отчета или не сдача долгосрочного домашнего задания - это неудовлетворительная оценка на экзамене.

Отчет оформляется в соответствии с методическими рекомендациями по оформлению письменных работ на кафедре, которые изложены в пособии [«Оформление письменных работ слушателей: учебно-методическое пособие. М.: , 2018, 132 с.»](https://gitwork.ru/sub/tpro/-/blob/master/info/%D0%9E%D1%84%D0%BE%D1%80%D0%BC%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5%20%D0%BF%D0%B8%D1%81%D1%8C%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D1%85%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82-2018.pdf).


Готовые стили и горячие клавиши реализованы в [шаблоне документа для ЛР](http://gitwork.ru/anetto/wiki/wikis/%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2).

Отчет должен содержать:
1.	Титульный лист (Отчет о выполнении долгосрочного домашнего задания по учебной дисциплине "Технологии программирования", вариант "Трон и т.п.", Этап 1 или 2 - два отчета, выполнили (список участников) и т.д.);
1.	Описание задания – в этом подразделе проводится полное описание задания этапа, описывается суть задачи;
1.	Основная часть:
    -	Описание выбранных инструментов программирования (язык программирования, среда разработки, операционная система, библиотеки и фреймворки, которые необходимо для работы - иными словами требования к программному окружению);
    -	Описание архитектуры (структуры) программы - из чего состоит, какой модуль за что отвечает;
    -	Описание работы по реализации задания, примеры работы программы (скриншоты).
1.	Выводы по результатам выполнения долгосрочного задания .

## Сдача

1. Демонстрация проекта на gitwork.ru
2. Демонстрация работоспособного ПО
3. Представление двух печатных отчетов

